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(g) Socket structure for concurrent multiple protocol access. 



@ In a multiprotocol environment, a new socket 
stnjcture is provided which moves the decision 
on which protocol to use until the time that the 
connection is actually made between nodes in 
the network. The new socket stmcture is 
CTeated for every endpoint. All the protocols 
which could potentially be used to send or 
receive data is sent a request to create a pro- 
tocol control block at the time the new socket is 
created. A selection process determines which 
of the protocols could be used by the endpoint 
The new socket then contains information on 
each selected protocol. At the time a connec- 
tion is established, any of the selected protocols 
could be used. The choice of which protocol to 
use can be based on user preferences, which 
protocols are availabie, the name of the service 
unit 
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BACKGROUND OF THE INV E NTION 

This invention relates generaily to data cornnriunicatioh In a network of conmputer systems. More particu- 
larly, it relates to a communicatioh endpbint structure which enables application programs resident on systems 

5 to communicate through such a network irrespective of the protocol for which the application was written and 
the protocols available on the network. 

Once upon a time, almost all computer systems were standalone processors to which private peripheral 
devices such as displays, printers and disk drivies were connected, acting independently from any other conrv 
puter system. Yet. it became apparent thiat there were substantial gains to be ntade if several computer sys- 

10 terns could be cooperatively coupled together. Today, it has become commonplace to couple a multitude of 
computer systems into a distributed environment such as a local area or wkie area network. 

However, there are many vendors who have developed their own hardware and software solutions for in- 
tegrating multiple computer systiems. In particular, they have developed different ideas of the format and pro- 
tocols that should be followed in transporting data through the networks. Some protocols support expedited 

15 data transmission by bypassing the standard data flow controls; others require all data to go through the con- 
trols. Specialized protocols are used for transport tasks such as establishing and terminating connections be- 
tween computer systems. Examples of well known communication protocols include System Network Archi- 
tecture (SlslA). Digital Network Architecture (DECnet). Transmission Control Protocol/Internet: Protocol 
(TCP/IP). Network Basic Input/Output System (NetBIOS). Open Systems Snterconnectksn (OSI) and AppleTalk. 

20 Other protocols are known and widely used. 

Most distributed application programs are Witten to an application programming interface (API) which as- 
sumes a particular communications protocol. However, the distributed environments which most organizations 
have assembled are quite complex, comprised of confederations of individual networks running different com- 
munication protocols. If the transport protocols assumed by the distributed application's API and the transport 

25 protocols actually implemented in one or riiore of the networks on which the orgsni^ation would like to send 
its data are not the samei the use of the applicattbh is limited: The problems of suci'i heterogeneity in commu- 
nications protocols is expectedUb get vvorse' as rrte begin to communicate with each other 
through their networks to perfonifi order prbcessVng.' diired'bining or other aoss o^^ activities. 

While the distributed applications could be rewritten §b tiiat they can run over each transport protocol or 

30 application gateways can tie written fdr each distribu^^^ applications, the cost of having pro- 

grammers write all the necessary code rnakes thfes'e' fiippVdache solu- 
tion is presented in copending application. Serial No. 731,564, entitled "^ompensationfor Mismatched Trans- 
port Protocols in a Data Communications Network", by R.F. Bird etal; filed July 17, 1991 and hereby incorpo- 
rated by reference. The incorporated application teaches a transport connection layer between a first transport 

35 user Sit one node in the network and a second tran^(k)rt User at a different node In tiie network. When the 
transport protocol assuniied by the application at the first node is not available in the network, the data being 
transferred between the two nodes is automatically altered to be compatible with the available transport pro- 
tocols. Thus, an p^anizatioK is at>le to choose applicatiori progranrts solely on the basis of the functions they 
provide, rather than the protocols which the^^ 

40 The above referenced application teaches a generalized transport layer. One of the transport structures 

which is presently used in the Berkeley version of the UNIX(TM)environmsnt is called a socket. A socket is an 
object that identifies a communication endpoint in a network. A socket hides the protocol of the network ar- 
. chitecture beneath from the application. A socket allows the association of an endpoint, such as an application 
pnjgram, with one of the selected protocols. This association occurs when the endpoint is created. An endpoint 

45 creation implies a static association of the socket with the protocol, which will remain invariant. However, in a 
multiprotocol environment, as described in the above referenced application, which facilitates heterogeneous 
connectivity, a transport endpoint may need to bound to any of several connectivity, a transport endpoint 
may need to be bound to any of several available protocols after the creation of the endpoint. Therefore, if 
sockets are to be used in such an environment, a new socket structure which allows dynamic association of 

so the socket with the protocol must be devised. The present invention teaches such a socket structure. 

Summary of the Invention 

The present invention provides a system and a method for communicating between nodes in a computer 
55 network in which a plurality of protocols are useable by network nodes, the method comprising the steps of 
creating communication endpoint objects defining communication parameters for respective network nodes, 
the objects having information about the plurality of protocols which are useable by said node for inter-node 
communication; and at the time communication is requested between said nodes, establishing a connection 
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between said nodes using a selected one of the plurality of protocols. , , ^ . . 

The present invention thereby facilitates late binding of an endpoint to a transport protocol in a distributed 
environment/enabMng a more dynanriic asspcial^oa b^ 

Preferably, the invention allows natiye acces^ to a prqtocc)! by an application. It is also preferred that the 
5 invention provides the necessary infonrn^yon , for .ripnrn^^^^ 

The invention provides, in a prefen-ed embodiment, a new socket structure which moves the decision on 
which protocol to use to the time that the connaqtlon is actually made between nodes in the network. In a mul- 
tiprotocol network, the new socket structure, can be created fpr every endpolnL For all pf the protocols which 
could potentially be used to send or receive data a reqgest is^ ma^f to .create a protocol control block at the 
10 time the new socket is created. A selection process dpterniines which of the prptocds could potentially be used 
by a given endpoint The new socket for the endpoint then contains information on each of the selected pro- 
tocols. At the time a connection is established, any of th^ selected protocols could be used. Native or non- 
native connections can be made. The choipe.of which, protopol tp use. or the order of protocol preference can 
be based on user preferences thrpugh configuration, (he jq^ pr infom?ation from the named service 

15 unit. ■ ::■ , , . , . ■ } 

Brief Description of the Drawings . - = : , : vv;. 

The inventk)n will now be described in morexJ^^il, by;^gy of e:?^ Werence to the acq^ 

20 drawings in which: ^- ; - ^ r 

FIG. 1 isadiagrarr)oftwosingieprptp<^LnetwqjK3^.^^^ 35r^, 

' work.. ■ . ■ -If '}:a\f?l*A^.>f-'! ^- ^:'^,::\' i-.-r . . /.^i 

FIG. 2 is a block diagram of ttie transport ioter^^ usei^cpp^^ an ernbpdimient of ^ in- 

vention. ■. - .c=;;.:-.V!.:- : r ■■ ' ■ i ; -^^ ^ v-"' r ,^ ./•.:.-c-C: . .: r.:yU.^--rr: ■. 

.25 FIG. 3 is a diiagramtof a conventional .gc^lff^t,;^^ S '.^^'^ . 

FIG^4 isa diagrampf the socketjcpntpoi . -^j^- 

; FIG. 5 is a flow diagram of the cr^tiqii^^ invention. 

FIG. 6 is a fiow^ diagnampf establishing^ - —i:^- 

using amuitiprotocQt^pcketacpprdinig^th^i^ . , . - r .'^..s^ 

30 ' FIG. 7 is.arepre®^ntatioi>.pf^vGomps^ ..^hs 
; FIG. B is a block diagram of thf^cp^ 

Detailed Description of the Drawtfigs ^^ ^ ^ . . ^ / ^ . . Ui- ; : : : 

35 The following descriptionv describes a; sod^^ 

socketsand could be applied to similar (apmnr)unic^^^^ > 

Although the follovying descriptkin cprv^ip^^ 
architecture to allow one skilled in the art;to.underisita to The 

Design and Implementation of the 4.3 Bs6 UlSllx dper^ing System by S, J. Leffer istal., 1^89 which is hereby 

40 incorporated by reference, for a mpre ppmpif te unc^ersta^ of operating sy^eim Jiase^ Berkley ver- 
sion of UNIXT^. Such operating systems anewell.^now^.' V,: . 

FIG. 1 shows three single protocol networks 10, 12. 14 which are mterconhected through a gateway 59 
built according to the principles pf the present invention. With the growth of network distributed environments, 
it is not uncommon to see networks using, four or fiyed if fererit protocols, such as TCP/IP. NetBIOS, SNA or 

45 AppleTALK. Since applications which run onpnenetworkwill not often run with application^ on theother, trans- 
port of data throughout the network is hindered. As discussed above, the MuitiProtocol Transport Network 
(MPTN) 16 as taught in the above referenced application addresses these problems by diefinirig an interface 
and a compensation mechanism to a set of transport services that provide connections across a plurality of 
transport protocols. By providing a transport boundary between the networks and the applications resident 

50 on systems. MPTN provides a common transport interface so that messages from ttie applications can be 
transported over any protocol in the network. 

As shown in FIG. 1 . hosts 20 and 22 are coupled to the nmjltiprotocol transport network 16. While the MPTN 
16 appears as though it is a single logical network having a single protocol, host 20 is coupled to a first network 
10 which communicates via protocol X. e.g.. TCP/IP. and host 22 is coupled to a second network 12 which 

55 communicates via protocol Y, e.g., NetBIOS. 

Application program A 24 resident in one of the hosts 20 coupled to the MPTN network 16 wishes to com- 
municate to application B 26 resident in another host 22 also coupled to the network 16. Upon application As 
call to the socket layer 27, a socket is created by the socket layer 27 defining application A as an endpoint 
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Sockets contain information about their type, the supporting protocols used in the transport layer 28 and their 
state. A connection request goes through the transport layer 28, the network layer 29 and the network interface 
layer 30 which add the necessary control and data inforrnation before the message is sent out on the network 
54. Compensation for the differences between protocol y and X is carried out by the transport layer as taught 

5 by the above referenced application. 

FIG. 2 depicts the code modules in. memory at a computer system which is coupled to the multiprotocol 
transport network in greater detail. The socket programming Interface 60 and common transport semiantics 
62 correspond to the socket layer and separate the applications 64, 66, 68 from the service drivers 70, 72, 
74. Three types of applications 64, 66, 68 are shown in the application layer. To utilize the socket structure of 

10 the present invention, NetBIOS applications would be rewritten to the socket API to become the NetBIOS sock- 
et application 66. The standard local IPC socket application 64 and TCP^P applications 68 are already written 
to a standardized socket programming interface and so would require an minimum of revisions. The connmon 
transport semantics 62, include the socket control blocks, which will be described in greater detail below. An 
interface between the socket layer and the transport layer is comprised by the local IPC service driver 70, the 

IS NetBIOS service driver 72 and the INet service driver 74 which correspond to the applications in the application 
layer. The service drivers are used to emulate.the cornmon transport semantics for the transport protocol driv- 
ers in the transport layer. In the present invention, they may also contain the compensating means described 
in the above referenced application which converts 3; message intended for a first protocol by the application 
to a second protocol supported by the network. The transport layer includes the NetBIOS 76 and TCP/IP 78 

20 protocol drivers which cause the application message to conform to the protocol format There is no corre- 
sponding local IPC module as it describes a local prptpool whose messages are not placed on the network. 
The network and network interface layers are not pictured, the latter would include device drivers for the I/O 
hardware v/hich couples the computer system to the network, e.g. a token ring or ethernet driven the former 
might include drivers written to the well known NDIS interface. 

25 A socket is the object in the Berkeley version of:UNIX(TM) from which messages are sent and received. 

Sockets are created within a communication domain as files are created within a file system. Aoommunication 
domain summarizes the sets of protocols, the naming conventions, the hardware which may t>e a particular 
network and may use an address which refers to the communication domain. The internet domain specified 
by the address family AF_INET; the NetBIOS domain is referenced by the address family AF_NETBIOS. Acon- 

30 nection is a means by which the identity of the sending socket is not required to be sent with each packet of 
data. The identity of each communication endpoint is exchanged prior to any transmisston of data and is main- 
tained at the transmitting and receiving nodes, so that the distributed applications at each end can request 
the socket information at any time. 

When an application creates a socket endpoint for a certain protocol and the protocol chosen by the trans- 

35 port network matches that protocol, native networking has occun-ed. For example, the INet protocol is used 
to support the INet address family and NetBIOS supports the NetBIOS address family. On the other hand, 
when the transport protocol does not match the socket endpoint of an applicatton it is termed non-native net- 
working. Using the present invention, however, the application is unaware that a different transport protocol 
is being used to connect with other nodes in the network. 

40 In the present invention, the socket interface is used to connect between replicas of a distributed appli- 

cation or the client and server portions of a client/server applicatton using a variety of transport protocols. The 
application can select the transport protocol or request that the socket layer determine the protocol. With the 
non-native networking feature of the present invention, applications written to communicate with one another 
using one protocol can choose to communicate on another transport protocol which might be optimized for the 

45 network environment For example, an application written for TCP/IP could communicate using the NetBIOS 
protocol over the network,giving the distributed application a significant performance gain. 

A conventional socket control block is depicted in FIG. 3, a socket control block 100 contains Information 
about the socket, including send and receive data queues, their type, the supporting protocol, their state and 
socket identifier. The socket control block 100 includes a protocol switch table pointer 104 and a protocol con- 

50 trol block pointer 106. The pointers are used to locate the protocol switch table (not pictured) and the protocol 
control block 102 respectively. The protocol switch table contains protocol related Information, such as entry 
points to protocol, characteristics of the protocol, certain aspects of its operation which are pertinent to the 
operation of the socket and so forth. The socket layer interacts with a protocol in the transport layer through 
the protocol switch table. The user request routine PR_USRREQ is the interface between a protocol and the 

55 socket The protocol control block contains protocol specific infonmation which is used by the protocol and is 
dependent upon the protocol. 

A socket control block according to the present invention is shown in FIG. 4. Here, the socket control block 
110 is shown broken into two sections, the main socket control block which is largely identical to the conven- 



4 



EP b bl3 274 A2 



tionarsdbk^t control bloiik above arid the MPTN extension 112 which contains ma^iy of the features Recessary 
fdr the present invention. Both are iinked together by a nruiltiprotocol transport network extension 113. Each 
of the protocols whioh could be potentially us^ to *end dr receive data is senta request to create a^rotocol 
control biock-120. 122 at thetirtie the new socket is abated. After a selection procedure, the "ev. ^°d<et then 
5 contains information regarding each selected protocol, the protocol switch table po.nter.114. ^^f . P~'°^ 
central block fKJinter 116. 119. and a pointer to a interface address .fappl.cablefor.the^part^^^^^ 
pictured). AS above, the protocol switch t^ble pointer refers to a respective protocol switch tatile which defines 
Lous dntry fKJints for that protocol; Alsb-f^ 

io ^"^tn^e time of socket creation, no connection is made td any particular protocoUo the application endpoint 
connection implies an association of the connecHon-requestor socketof tte 

donnection-aaeptor socket. It carf be viewed as^^cbrtimunicatton wire running betweerv the t>*(p^sod<ets that 
are -connected-; potentially in two differentcontinents.plrbvidingthe ability for both of them to send and receive 
messages. There is hb difference betweeh a triahsmitting socket and a receiving sooketfor the present inven- 

J5 tion. After a connection, each can send or receive data. ' ' ^ • ^ ^ „„.;„,h» a* 

The decision on which protocol to Use is del^iyed uiitil the time that the connection .s actuaHy made. At 
the time of establishing a connectibn. any ofthe network interfaces in a protocol could be used- The order in 
which the pointers whiiih refer to the protdtols and network interfaces is based on user preference, infomiation 
from the named sarVice unit dr the capability 6f tM^ protocol the socket extension 412. which cpnteins the pom- 

20 ters114 116 11 8 and 119. also indudbs state infdirnatlon on the socket and t^^ transport net- 

work The socketextenfeibh-112 is used by tlie socket layer to manage the socket and MRTN states. From the 
list of available prbtocdis, the socket (ayet picks thdse protocols that support the raquested so<*et domain and 
the type of coirirtiuniditiori (datagrams. st*aam«;et«^.^asd(^^^^ de- 
scribed below. . . " - - - . 

25 A sample 3bdcet cpWtrpI block structiifre ts(*gh/en^ ffi the code below.- 
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socketva.h 

Kernel structure per socket. 

Contains send and receive buffer queues. 

handle on protocol and pointer to protocol 

private data, error infornation and MPTN extensions. 

The first part of this structure ( upto the so iiptn field > is 

to the BSD4.3 socket control block. ^ 



identical 



V 

struct socket ( 

short so type 
short ~ ^ 
short 
short 
caddr t 
struct 



so_options: 
sojinger; 
so.state; 
so_pcb: 

prolosv far ^so.proto; 



/* generic type, see socket. h */ 
/* from socket call, see socket. h */ 
/* tine to linger while closing */ 



/* internal state flacs SS, ^ 
/* protocol control block */ 
/* protocol handle */ 



below •/ 



Variables for connection gueueing. 

Socket where accepts occur is so.head in all subsidiary sockets. 
If so_head is 0, socket is not related to an accept. 
For head socket sb_qO queues partially coiipieted connections, 
while so_q is a queue of connections ready to be accepted. 
If a connection is aborted and it has sc.head set, then 
it has to be pulled out of either so_qO or so_q. 
He allow connections to queue up based on current queue lengths 
and linit on^nuaber of queued connections for this socket. 



/ » 



struct' socket far *eo_head; 
struct socket far *so_qO; 
struct socket far *soIq; 
short eo_g01en: 
short so_qlen: i 
short so_qliBiit: 
short so.tineo: 
u_Ebort so_errcr; 
short so_pgrp; • ' - ' 
ujohq so_oob!iark; ' 
Variables for socket- buf ferinq; 



= /* back pointer to accept socket */ 
^ * /* queue of partial connections */ 
/* queue of inconinq connections */ 
/* partials on EO_qO */ 
: 7* nuaibor of connections on so_q */ 
/* aax number queued connections */ 
/* connection timeout */ 
/* error affecting connection. V; r 
pgrrp for signals */ ' • ^ 
>'-'/* \Gnars to cob fnark. */ . . ^ : 



struct sockbuf { 

u^long sbjcc/ ' 

u_long sb_hiwat: 

u^long sb_3ibcnt; 

u_lonq sblBibttax; 

a_long sb.lowat; 

struct nbuf far *sb_nb: 

struct proc far ^sb^seL; 

; - • short sb_tiineo; ' -T. j 
' short 



■ /* 
V* 
/• 
/* 
/* 



sb_f lags: 



} so_rcv. so_snd; 
/» MPTH SOCKET EICTEHSION */ 
struct n_esock far * so^siptn; 



/* 



actual chars in buffer/*/ 
siax actual char count */ ^ ■ ■ 
chars of- mbufs used */ - 
Biax chars of iribufs to use *./ 
low water mark (not used, yet) ♦/ 

/* the nbuf chain */ 

/* process selectino read/write */ 
tineout (not used yef.) */ 
flags, see below */ , - 



V* socket MFTN extensinns */ 



»def ine 36 MAX 
#define SBILOCK 
«define SB_«AJ3T 
IWefine S^JhU 
idefine SB_SHt, 
«def ine Sljm. 
}; 



((tt long)<64*1024L)) 
0x01 
0x02 
0x04 
OxOfi 
0x10 



/* max chars in sockbuf */ 
/* lock on data queue (so^rcv only) */ 
/* someone is valtinq to Tock */ 
/* someone is waiting for data/space */ 
/* buffer is selected */ 
/* collision selecting */ 



55 



/* Socket extensions for MPTK 

* The socket control block points to this structure which contains 

* all the MFTM related socket extensions. 

* Since ii_esock. the HPTN extensions to sockets, is contained in one 

* nbuf, we could use the rest of nbuf space to accommodate the pcb 

* pointers. 
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*/ ' _ ' _ '' r^-'C.:' • 

/« defines the structure for storing additional ^pointers.; • : 

* used in n esock. m' ^'-'.^ .'. J'j'r'w 
» The structure n.addr defines the address/ format- It :is defined in :^ptpder.n. 
» The structure n info defines the user specified connection characteristics 

» and is defined In nptndef.h. • ■ ' ' ^ ^r^^'r^na n^f 

» The structure bnlst defines the user configured protocol preference list 

* and is defined in nptndef.h. ' 



struct n^sopcb ( 

struct protosw far * so_proto;' 
caddr.t so_pcb: i ^ ' 
struct n_a<Wr far * soibnsap; 



): 



/* protocol switch .ptr */ 
/* pointer to the PCB */ 
/* the networi? interface 
* the PCB refers to */ 



struct t.conn.stat ( 
char type; 

char index; 



caddr t ftnan; 



/* DST BNSiff fOUND.USE PREF/LIST:CAGHE; : 
• GH NEXT HS*. GK^BNSAP */ : ^ r - 
/* current network; . :as an index in , to the 
. Vpref/ listtiisi the casejcis.i;^ u < - 

•,v:-, ■ i:.v ■---^} 

/* destiriati«K;hairevr;:fdr:.ABM casevi-Gatcway , 

* cases, it is dst_b_nain. 
, * In the native case or cache case, contains 
: ♦ the dest A-adidr::> . 



struct hnlsb^far .*prf 1st: A* pcrlnbcr^to the pref list 



) 



struct n esock^ f::^''-:-' . 'jOji ^--^r -;:'i -:_of. 

int <* io_upcaH ) (): us^:u|>call address V y . - 

struct socket far • so irelavi r/^ jeby socket pointer:fpr gateway only:*/ 
* -- /* comiectwi fcn^Krs.glv^n at/m:,create()*/ 

/♦ conn. char of a connection */ 
/* user specified doBaijiv*/-- 
;.y:**iocal user nane V ot: - 
-/!* "^peer useri ^aame */ r . i 
;^.r/.^ Hronnectiqit/itei-ininatj^.data */ 

v/i* • exped i t ed »d a * /r; i - . ; 
v,'/'* linked list^C nonnitiye'scbs.to search 
. * foriuser-naBtesiV. ^ . : - 
U1I6XUUCU «,i._..Kv« : . ^ npUi flags ;havAnq the following defs*/ 
struct B conn Stat conn. stat^t :/**to naintatnpnptn-conneot status */ 
short so'pcbnun : : : 7* number of pcbs currently in sopcbl 1 */ 

lonq so'pcbstat: /* pcb state: bit position corresponds to 

^ * pcb array; 0->in-u5e; else not-in-use*/ 

struct n sopcb sopcb IMPTN HAXPCBI;/* array of n^sopcb structures */ 



struct B_info far 
struct B.info far 
short so_donain: 
struct Djaddr far 
struct B.addr far 
struct nbuf far * 
struct Bbuf far * 
struct socket far 



io_iiuo; 

* so„cinfo: 

* sD^lanan;;. 

* so^panan: 
soictdata : 
so'expdat; 

* so n«it- 



uns igned so_i!ptnif 1 ag ; 



Mefine MPTILNONHATIVE 0x01 

idef ine MFTHJATI VE ' 0x02 

#define MPTN.SOJIWD 0x04 

tdefine MPTN SO UNBIND 0x08 

tdef ine MPTN_SO_CONH 0x10 

itdefine MPTN_SO.H(M)RB_CONK 0x20 

ftdef ine MPTN_SO_LlSTEN 0x40 

Mefine MPTN_SO_CON_HEAD_HAIT 0x80 



(Wefinc MPTN. 
iWefine MPTN 
ftdefine MPTN. 
idef ine MPTN 
Wefine MPTN 



SO CON HEAD.RCVD 0x0100 
'SOlCC»l*HEAD SENT 0x0200 
SO.CONlESTABLlSHED 0x0400 
SO.CLOSED 0x0800 
SO BCAST FCV 0x1000 



•define MPTN.SO.IN.ADDR.ANY 0x2000 



/* indicates nonnative connection */ 
/* indicates native connection f/ : 
/* sock Biptn state->addr bound */ 
/* sock nptn state=>addr not bound*/ , 
/* sock nptn state=>connect req is nade*A 
/* ->there will be no nore conn, re- try 

* over other networks/ protocols*/;. 

/* init state of a passive sock */ . ^ . 
/* native con set up. .waiting for, MPTN 

* connect header */ 
/* passive node...Biptn con rcvd. 
/* Active node...inctn con sent . 
;/* Connection established ...*/ . 
/* local socket close issued */. 
/* the socket is enabled to rev 

* broadcast dgns.*/ 

/♦ the socket is bound to in_addr_any */ 



.*/ 
.*/ 



}; 



/* 
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/* no file table ref,any more */ 
/* socket connected to a peer */ 
/* in process of connecting to peer */ 
/* in process of disconnecting »/ 
/♦ can't send more data to peer */ 
/* can't receive wre data from peer */ 
/* at Htark.on input *i 

/* privileged for broadcast, raw.'. . */ 
/* non-bJocking ops */ - : . 

/* asynci/o notify */ ■ , , . . 

/* cancel call V 
/* seen push */ 

/*Refft of the info is the same as in the BSD4,3, socketva.h */ 
Copyright. IBM Corp. 3993 

Conventional socket creation starts with a call to the socket API. Adornain table is searched for the address 
family, the type and protocol which is desired by the application. If a nnatch is found the protocol switch table 
entry is set in the socket control block. Next, the user requests entry and the selected protocol is called to 
create of the protocol control block. If a match is not found inihe dojnain table forjhe address family, type and 
protocol desired by the application, ah error is returned to the application. 

FIG. 5 depicts the process of creating a socket according to the present invention. The process begins 
with a socket creation request 150 froFin an. application to the socket API, the application wishes to send or 
receive data across the network. The command to ths^spcket API for the request takes the form of socket=(AF, 
*, type; proto):"AF? refers to the address family and corpmunfcation domain; "type" refers to one of the socket 
types defined in a system header file. The "proto" or protocol paranr^eter is used tojndicate that a specific pro- 
tocol is to be used: A test is performed in step 1 52: tOidetermi.ne if "prcto" ss specif ied. If so, the normal socket 
creation process in step 1 54 is carried out and:the' process ends,;Step 1 55. . . 

If "proto" is not specified, the process continues tpicreatia a mult I protocol, s is associ- 

ated with a protocol sv/itch table. For each ^protocciifs^tfitch .table, step 155. tests are performed whether the 
type and address family of the requesting endpoint. steps^l 58. and 16Q, are matched by the protocol. In step 
158 the test for "type" match is performed. If the test fails, the process returns for the. next protocol switch 
table, step 156. If the test succeeds, the test for address fanriily match is performed in step 160. Both the "type" 
and "fartitiy" are represented as integers. By matching^ the socket layjsr compares the 'type* and "address fanrv 
ily** field supplied by the user arid the 'type* and "address family" fields in the. protocol. If a match is found for 
both type and address fsmiiyi the protocol is selected^s a candidate protocol and set in the socket extension 
vvith pointers to the protocol switch table and protocor control block, step 162. If there is no match, the process 
determines whether the address family is supported non-natively in the network, step 164. If the protocol is 
supported, step 166, the protocol is selected as a candidate protocol and set in the socket extension with poin- 
ters to the protocol switch table and protocol control block, step 162. If the protocol is not supported, in step 
166, a testis performed to determine whether it is the last protocol switch table. If not the process returns to 
step 156. If it is the last protocol switch tebie, the process ends, step 170. The protocol pointers can be reordered 
within the extension according to the application or user preference through the use of a configuration tool or 
according to information from the named server. . 

In FIG. 6, the process to establish a connection using the multiprotocol socket is described. The process 
begins in step 200 where the socket layer tries connecting to a specified destination using the first protocol 
from the list of protocols in the socket extension. The choice of which of the protocols to try first can be based 
on the configuration of user specified preference order of protocols. If the connection succeeds, step 222, the 
process ends in step 223. If not, the next protocol is used to try to establish a connection in step 224. Tests 
are performed determine whether a connection is made, step 226. If so. the process ends. If a connection is 
not made, a test Is performed to determine whether it is the last protocol in the socket extension. If not, the 
next protocol in the extension is tested, step 224. If all the protocols used when creating the socket have failed 
to provide the connection, the transport provider returns a notification of failure to the application, step 232. 

As mentioned previously, the invention finds use in a plurality of computers which are part of a network 
such as a Local Area Network or wide Area Network. Although the specific chofce of computer in these net- 
works is limited only by performance and storage requirements, computers in the IBM PS/2 (TM) series of com- 
puters could be used in the present invention. For additional information on IBM's PS/2 series of computers. 



:* Socket state bits: 

*/ • ■ ■ 

MefiiK SS MC^REF 0x001 . 

Sdefine SS2iSC0NNBCTB0 ' 0x002 

«define SS ISCOHNBCTIHG - 0x004 . 

tdefine SS"lSDISCOfWKTI»G 0«008 . 

«def ine SS CAKTSENDHORE 0x010 

»def ine SS CAKTRCVMORB ' 0x020 

«def ine SSlRCVATMARK 0x040. . : 

Jdefine SS_PRIV . 0x080 

tdefine SS HBIO ■ OxiOO 

«define SS'ASYfec 0x200 



Mefine SS CANCEI, ' ' 0x4000 

ftdefine SSIpUSBSSEN 0x8000 
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the reader is referred to Technical Reference Manual Personal Systems/2 Model 50, 60 Systems IBM Corpor- 
ation. Part No. 68X2224 Order Number 568X-2224 and Technical Reference Manual Perso nal Systems/2 
(Model 80) IBM Corporation Part No, 68X 2256 Order Number S68X-2254. One operating system which an 
IBM PS/2 personal computer may run is IBM's OS/2 2.0 (TM). For more information on the IBM 0^/2 2.0 Op- 
erating System, the reader is referred to OS/2 2.0 Technical Library. Prog ramm ir^q guide Vol. 1. 2. 3 Version 
2.00 Order Nos. 10G6261, 10G6495. 1006494. In the alter nativis. the compiler system miightbe in the IBM 
RISC System/6000 (TM) line of computers which run on the AIX (TM) operating system, the viarious models 
of the RISC System/6000 are described in many publications of the IBM Corporatidn. for example, RISC Sys- 
tem/6000. 7073 and 7016 POWERstation and POWERserver Hardware Technical reference. Order No. SA23- 
2644-00. The AIX operating system Is described in General Concepts and Procedure-AlX Vers ion 3 for RISC 
System/6000 Order No. SC23-2202-00 as well as other publications of the IBM Corporation. In lieu of the cited 
references, the reader is offered the following general description of a computer system which cou*d be utilized 
to practice the present invention. 

In FIG. 7, a computer 310, comprising a system unit 311 , a keyboard 312, a mouse 313 and a display 314 
are depicted. The screen 316 of display device 314 is used to present the visual changes to the data object. 
The graphical user interface supported by the operating system allows the userto use a point and Shoot method 
of input by moving the pointer 315 to an icon representing a data object at a particular location on the screen 
316 and press one of the mouse buttons to perform a user command or selection. . 

FIG. 8 shows a block diagram of the componerits.df the eomputer shown in FIG. 7.. The system unit 11 
includes a system bus or plurality of system t>Uses 21 to which various components arecoupled.and by which 
communication between the various components >is-<accomplished. The microprocessor 322 is conaected to 
the system bus 321 and is supported by read only memory (ROM) 323 and random acce^ memory (RAM) 
324 also connected to system bus 321. A rnicroprocessor iathe ISM multimedi.a:PS/2 series of computers is 
one of the Intel family of microprocessors ihdudin^i -the 386 or 486 tnicfoprocessors., Hqy^eyef, pther micropro- 
cessors included, but not limited to; Motorola's family bf microprocessors such as^he 68pop,,68020 or the 
68030 microprocessors and various Reduced TnStriiCtion Set Computer (RISC) micropipcessprs manufactured 
by IBM. Hewlett Packani, Sun. Intel, Motorola and ^oth^i may be use* in the spepifiq 

the ROM 323 contains among other code tH^ B^fitic Input-Output system (BIOS) which controls t)asic hard- 
ware operations such as the rhteractlon knd th^dfefcdrivesand the keyboard. The RAM 324 fe the rnain memory 
into which the operating system. transport p^ loaded. The memory man- 

agement chip 325 is^connected to thiB systenri bus^321iam*controls direct memiCMry access operation^ including, 
passing data between the RAM 324 and hafd^tsk^drive 326 and^oppy disk driv^;327 CD ROM 332 is 
also cbupieid to the systenri bus 321 . ^ - ■ ^-^'^^^'^ ' - - ■. i .;'v- | : ; -t , - , . ; 

Also connected to the system buis 321 are -varldufe 1/0 cont roll ^ controller 328, the mouse 

controller 329, the video controller 330, and the audio controller 331 which contnol their r^spectiy^ hardware, 
the keyboard 312. the mouse 313, the display:3t4 and the speaker 315. Also coupled tq the system bus 321 
is the digital signal processor 333 which c6!^ and is preferably 

incorporated into the audio cbntfoller 331. Arr I/O con^ 
munication over a network 342 to other ^irnilarly^^^^^ 

While the invention has be^n described With respect to particular embodiments above, it wilt be understood 
by those skilled in the art that modifications nriay be made without departing from the spirit and scope of the 
present invention. The preceding description has described the principles of the present invention in terms of 
a particular communications endpoiht object, a socket, in the socket layer betvyeen the application layer and 
transport layer. The principles of the mvehtioh could be extended to provide similarly configured communica- 
tion endpoint objects in other layers. For example, an object in the network interface layer could be used to 
monitor a plurality of underlaying MAC drivers to that data could be sent or received over a plurality of MAC 
protocols to different types of networks. These embodiments are for purposes of example and i llustration only 
and are not to be taken to limit the scope of the invention narrower than the scope of the appended claims. 



Claims 



A method for communicating between nodes In a computer network in which a plurality of protocols are 
useable by network nodes, the method comprising the steps of: 

creating communication endpoint objects defining communication parameters for respective net- 
work nodes, the objects having information about the plurality of protocols which are useable by said node 
for inter-node communication; and 

at the time communication is requested between said nodes, establishing a connection between 
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said nodes using a selected one of the plurality of protocols. 

A method according to daim 1, wherein the: selected protocol is chosen based on user preferences. 

A method according to claim 1, wherein the selected protocol is chosen based on a capability of the se- 
lected protocol. 

A method according to any one of the preceding claims, whereih-the creating step comprises the steps 
of: ■ ; ' • : -"V 

requesting information of each of the plurality of protocols; 

selecting a set of protocols from the plurality of protocols, which selected protocols are useable by 
the respective nodes; 

building a protocol control block for each of the selected protocols; and, 

inserting a pointer in the communication endpoint object for each protocol control block of a se- 
lected protocol. 

A method according to daim 4, wherein the order in which the pointers are inserted is based on user pref- 
erence. 

A method according to "daim 4 wherein the seleicting. step comprises the steps of: 

determining whether there is a match for a ffi-st protocol for a first set of protocol parameters, the 
first protocol corresponding to a first pointer in the socket; and, 

responsive to finding no match'for the first protocol, determining whether the first protocol is sup- 
ported non-natively in the network. ^ 

A system for communicating between nod^s in a computer network in which a plurality of protocols are 
useable by network nodes, the system conriprissng:.'*' 

means for creating communication ehdpoint objects defining communication parameters for re- 
spective network nodes, which objects liave information atxjut the plurality, of protocols useable by re- 
spective computer systems each coupled. to one or more nodes jn the rietwbi'k; and, 

means for establishing a connection between a first and a second computer system using a se- 
lected one of the plurality of protocols at the time communication is requested between nodes on the dif- 
ferent systems. .; , . ^ . y 

A system according to daim 7, which further comprises: .... 

means for selecting a.set of prqtocpis from said plurality of protocols; 

means for requesting information from each of the plurality of protocols; 

means for building a protocol control; block for each of the selected protocols; and, 

means for inserting a pointer In the communication endpoint object for each protocol control block 
for a selected protocol; 

A system according to daim 8, which further comprises: 

means for determining whether there is a match for a first protocol for a first set of protocol para- 
meters, the first protocol conres pond injg to a first pointer in the socket; and, 

means for determining, responsive to finding no match for the first protocol, whether the first pro- 
tocol is supported non-natively in the network. 
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Socket structure for concurrent multiple protocol access. 

(57) In a multiprotocol environment, a new socket 
structure is provided which nrraves the decision 
on which protocol to use until the time that the 
connection is actually made between nodes in 
the network. The new socket structure is 
created for every endpoint. All the protocols 
which could potentially be used to send or 
receive data is sent a request to create- a pro- 
tocol control block at the time the new socket is 
created. A selection process determines which 
of tt^e protocols could, be used by the endpoint 5 
The new socket then contains^ infonhatibn bn^ 
each selected protocpio At the ^tinrie a conn^c-| 
tion is established, any of the selected protocols^ 
could be used. The choice of .which prpiicolito: 
use can be based on user preferences, which 
protocols are avaSable, the name of thei service 
unit . 
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